cited in the European Search 
Report of EPO?'/^ 01 {,2-^ 
Your Ref.:.(^.1f^-t?:5-y^ • 



(19) 



J 



(12) 



Europdisches Paterrtamt 
European Patent Office 
Office europ^en des brevets (11) 

EUROPEAN PATENT APPLICATION 



EP 0 933 900 A2 



(43) Date of publication: 


(51) Int. Cl.^: H04L 12/46. H04L 12/44, 


04.08.1999 Bulletin 1999/31 


H04L 12/40 


(21) Application number: 99250033.0 




(22) Date of filing: 28.01 .1999 




(84) Designated Contracting States: 


(72) Inventor: Matsuda, JunichI 


AT BE CH CY DE DK ES R FR GB GR IE IT LI LU 


Minato-ku, Tokyo (JP) 


MC NL FT SE 




Designated Extension States: 


(74) Representative: 


AL LT LV MK RO SI 


PatentanwSlte Wenzel & Kalkoff 




Grubesallee 26 


(30) Priority: 29.01.1998 JP 1736898 


22143 Hamburg (DE) 


(71 ) Applicant: NEC CORPORATION 




Tokyo (JP) 





(54) Bridge for the IEEE 1394 bus 

(57) An initialization of local buses 14a to 14n, a 
definition of topology and a management of iso- 
chronous resources are performed for every local bus. 
Each of portals 12a to 12n includes an asynchronous 
packet discriminator 215 which discriminates an asyn- 
chronous packet sent by a terminal device and transfers 
it The portals 12a to 12n discriminate asynchronous 
packets sent by terminal devices in order to acquire iso- 
chronous resources and secure isochronous resources 



on different buses. The portals 12a to 12n transfer iso- 
chronous packets to different local buses by associating 
a received isochronous packet with a plug on the bridge 
bus side and a plug on the local bus side with an iso- 
chronous channel on the bus. Thus, the utilization effi- 
ciency of bus resource in a serial bus network is 
improved ard a packet sent from a terminal device can 
t>e transferred to a different bus. 



11 



13 



15 



IEEE 1394 Bridge 



Bridge 
Manager 





Portal 




14a^ 


12a 



Portal 



14b^ 



12b 



Portal 



14c- 



12c 





Portal 


















12n 


14n-^ 





CM 

2 FIG.5 

o 
o> 

CO 
CO 

o> 
o 

LU 

Primed Xerox (UK) Business Services 
2.16.7/3.6 



JSDOCID: <EP 0933900A2_I_> 



1 



EP 0 933 900 A2 



2 



Description 

CROSS REFERENCE TO RELATED APPLICATIONS 

[0001] The present invention claims priority from Jap- 
anese Patent Application No. 10-017368 filed January 
29, 1998, the contents of which are incorporated herein 
by reference. 

BACKGROUND OF THE INVENTION 

1 . Field of the Invention 

[0002] The present invention relates to a bridge for 
performing a transmission/receiving of signals between 
mutually independent serial buses in a serial bus net- 
work constructed with a plurality of terminal devices 
connected through the serial buses and. particularly, an 
apparatus and method for initializing the network con- 
nected to the bridge and defining a topology and an 
cipparatus and method for transferring packets in the 
network. 

2. Description of Related Art 

[0003] In response to the request of improvement of 
the data processing capability of a computer and the 
request of processing of a large amount of data in such 
a case of a motion picture, the request of transfer of a 
largie amount of data between devices is being 
increased recently. 

[0004] As a serial bus suitable for a transfer of a large 
amount of data, a high-speed serial bus standardized 
by IEEE (the Institute of Electrical and Electronics Engi- 
neers) 1394 is known. Such high-speed serial bus will 
be referred to as "IEEE 1394 Serial Bus", hereinafier, 
and is disclosed in detail in "IEEE Standard for High 
Performance Serial Bus" IEEE, Inc., 96.8. 
[0005] When the IEEE 1394 serial bus is used, it is 
possible to connect respective terminal devices in a 
daisy chain connection and to connect them in a star 
connection by branching a plurality of wiring from each 
device. Further, it is possible to construct a network in 
which the daisy chain connection and the star connec- 
tion are provided in a mixed state. Fig. 1 shows an 
example of the network using the IEEE 1394 serial bus. 
[0006] The IEEE 1394 serial bus transmits data 
formed according to the GSR architecture defined by 
IEEE 1212. Data formed according to the GSR architec- 
ture forms an address space and upper 16 bits of this 
address space are used to specify a terminal device. 1 0 
bits among the upper 16 bits represent a bus_ID speci- 
fying a serial bus, the renr^ining 6 bits represent a 
nodeJD specifying the terminal device. Therefore, the 
network for transmitting data formed according to the 
GSR architecture can be provided with 1023 buses at 
maximum and 64 terminal devices at nnaximum can be 
connected to each of these kjuses. Data whose value of 



bus_ID is 1023 represents data to be transmitted to a 
local bus. that is, a bus directly connected to a terminal 
device from which the data is transmitted, and data 
whose node^lD is 63 represent data to be transmitted to 

5 all of the terminal devices in the network, that is, data in 
"broadcast address**. Therefore, the number of terminal 
devices which can be connected practically to the net- 
work for mutually connecting the terminal devices 
through a single bus is 63. 

10 [0007] In Fig. 1 , the terminal devices 291 a to 291 g are 
mutually connected through twisted pair lines 292 with 
feeder lines, each twisted line functioning as a transmis- 
sion line as well as a feeder line, and the terminal 
devices apply a predetermined bias voltage to the 

15 twisted pair lines 292. 

[0008] In the network shown in Fig. 1 , when an inser- 
tion of a new terminal device to the network or a sepa- 
ration of a terminal device connected to the twisted pair 
line 292 occurs, that is, when a new terminal device is 

20 connected to a twisted pair line 292 or a terminal device 
is disconnected from a twisted pair line 292, the bias 
voltage applied thereto is changed. Therefore, an occur- 
rence of the insertion or separation of a terminal device 
with respect to the twisted pair line can be detected by 

25 the terminal devices connected to the twisted pair line 
by detecting the change of the bias voltage of the 
twisted pair line. 

[0009] A terminal device which detects the occun-ence 
of the insertion or separation of terminal device with 

30 respect to the twisted pair line sends a bus reset signal 
for initializing the network to the twisted pair line. In 
response to the bus reset signal, the respective terminal 
devices cancel a network topology information thereof, 
that is, an information indicative of the bus in the net- 

35 work and the terminal devices connected to the bus. 
stored therein to allow the whole network to be initial- 
ized. Transmission and/or receiving of packets between 
the respective terminal devices become impossible dur- 
ing a time in which the network initialization is per- 

40 formed. 

[0010] After the initialization of the network is com- 
pleted, a re-definition of topology, that is, on update of 
network topology information, is performed automati- 
cally and a route node of the network, that is, a terminal 

45 device which manages control rights of the respective 
buses in the networK is determined. Thereafter, 
node_ID's are re-assigned to the respective terminal 
devices. In this case, an isochronous resource manager 
(IRM) for managing a isochronous source, that is, an 

so isochronous channel for performing an isochronous 
transmission and a bandwidth to be used, is also deter- 
mined. Details of this matter is indicated in IEEE 
1394.1995 Appendix E.3.1 -E.3.4. 
[0011] Since the initialization of the network and the 

55 setting of the terminal devices due to the insertion or 
separation of terminal devices with respect to the 
twisted pair lines are automatically performed, a user of 
the network is not required to be conscious of the state 
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change of the network. 

[0012] On the network using IEEE 1394 serial bus 
such as shown in Fig. 1, a communication of asynchro- 
nous data (data for asynchronous transmission) and an 
isochronous data (data for isochronous transmission) s 
are possible. In the network shown in Fig. 1 , when a ter- 
minal device wishes to transfer a packet, an arbitration 
sequence defined by IEEE 1394.1995 is performed first. 
That is, the terminal device requests the route node a 
bus control right and, when the bus control right is given io 
from the route node to the terminal device. It can trans- 
mit the packet. Details of the arbitration sequence is dis- 
closed in IEEE 1394.1995.3.7.3.2. 
[001 3} Further, since It is possible to guarantee the 
isochronous data transmission in the network using is 
IEEE 1394 serial bus, the isochronous data communi- 
cation is possible. As mentioned above, in the network 
shown in Fig. 1 , one of the terminal devices performs 
the IRM function of the bus resource of the serial bus 
network. The terminal device which transmits the iso- 20 
chronous data irtquires the IRM of available iso- 
chronous resource by using an asynchronous packet 
before the transmission of the isochronous data. That is, 
the terminal device reads values of a 
BANDWIDTH^AVAILABLE register and a 25 
CHANNEL_AVAILABLE register which are provided in 
the IRM and store an information indicative of iso- 
chronous resource which can be utilized by the network 
by performing a quadiet read transaction (data read) 
with using an asynchronous packet having a data struc- so 
ture shown in Fig. 2. Bj^-^, 
[0014] The terminal device which inquired the aHI^ 
bie isochronous resource confirms whether or noRt is 
possible to acquire an isochronous resource necessary 
for transmission of the isochronous data on the basis of 35 
the information obtained as a result of the inquiry and, 
when it is possible to acquire the isochronous resource, 
the terminal device performs a lock transaction with 
respect to the IRM by using an asynchronous packet 
having a data structure shown in Fig. 3. That is, the ter- 40 
minal device transmits an asynchronous packet which is 
shown in Fig. 3 and has a value *'0002*' in its 
extended_tcode field 64. Then, contents of the 
BANDWIDTH_AVAILABLE register and the 
CHANNEL_AVAILABLE register are compared and 45 
swapped with each other. That is, data stored in these 
registers are compared with data to be written in these 
registers and portions of the stored data which are dif- 
ferent from the data to be written are updated. When the 
comparison and the swapping are completed, the termi- so 
nal device becomes in a state in which it can transmit 
the isochronous data. 

[0015] Further, in the network using the IEEE 1394 
serial bus. one of the terminal devices becomes a route 
node, as mentioned previously. The terminal device as ss 
the route node sends a cycle start packet having a pre- 
determined format to a bus with a predetermined time 
interval. A terminal device which acquired the iso- 



chronous resource of the bus transmits isochronous 
data every time it detects the cycle start packet. In this 
manner, the route node guarantees the isochronous 
data communication, that is, the isochronous transmis- 
sion, of the terminal device v^ich acquired the iso- 
chronous resource with the predetermined time interval. 
[0016] There is a method of constituting a network by 
connecting a plurality of independent serial buses by 
means a bridge. Fig. 4 shows a bridge standardized by 
P1394.1 Draft Standard 0.02 and a concept of a net- 
work using the bridge. In Fig. 4, a bridge 321 is 
equipped with two or more portals 322a to 322c. The 
bridge 321 connects serial buses (local buses) con- 
nected to the respective portals to each other and the 
bridge 321 and these local buses constitute a network 
called "serial bus network^ 

[0017] It should be noted that, although PI 394 Draft 
Standard 0.02 discloses a concept of the bridge, con- 
tents of registers included in the respective portals and 
a basic procedures of a packet transfer, there is no indi- 
cation of a content of a switching function of the bridge, 
that is. a function to be performed by the bridge in trans- 
ferring a packet, in PI 394 Draft Standard 0.02. 
[0018] Further, in transferring an asynchronous 
packet in P1394 Draft Standard 0.02. a content of 
destination_ID in a header 61 of the asynchronous 
packet is judged by a portal and an input/output of the 
asynchronous packet between a local bus and a trans- 
mission path within the bridge is controlled according to 
a result of the judgement. 

[0019] Further, in transferring an isochronous packet 
in PI 394 Draft Standard 0.02, a channel to be used by 
the isochronous packet to be transferred is preliminarily 
assigned and the isochronous packet is transferred by 
using the assigned channel. However, no standardized 
procedure for assigning the channel is disclosed in 
P1394 Draft Standard 0.02. 

[0020] In the isochronous packet transfer mentioned 
above, "plug" and "plug control register (PGR)" defined 
by lEC 61883 are used. A plug is a virtual port for per- 
forming an input/output of isochronous data. The plug is 
not a physical port which functions as a plurality of plugs 
for controlling a plurality of data flows. The PGR is a reg- 
ister for writing an information indicative of isochronous 
channel number and occupied bandwidth used by the 
plug in transferring isochronous data between ports of 
devices which transmit data by using IEEE 1394 serial 
bus. The plug is coupled to the isochronous channel 
and disconnected from an isochronous channel by writ- 
ing, therein, data stored in the PGR. 
[0021 ] Incidentally, although the plug and the PGR are 
not standardized by IEEE 1394.1995 standard, they are 
practically mounted on audio visual (AV) devices, etc.. 
and will be standardized by P1 394A which is an amend- 
ment of IEEE 1394.1995. 

[0022] A first problem of the above mentioned prior art 
is that, since the initialization of the network and the 
redefinition of topology are automatically executed 
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every time when the twisted pair line is inserted or dis- 
connected within the network and the packet transmis- 
sion and/or receiving becomes impossible during the 
time in which the network is being initialized, the utiliza- 
tion efficiency of bus becomes low. 
[0023] There is no concrete method for solving the 
problem of low utilization efficiency of bus due to the ini- 
tialization of a network and the redefinition of topology in 
the above mentioned PI 394.1 showing the method of 
constituting a network by connecting a plurality of serial 
buses by using a bridge. 

[0024] A second problem of the prior art is that the 
number of terminal devices which can be connected to 
a network is limited to 63. 

[0025] A third problem is thai, when some of the ter- 
minal devices within the network acquire a larger 
amount of resources of the serial buses than others, a 
communication between the other terminal devices may 
become impossible. 

[0026] That is, in the above mentioned network, ai! of 
the terminal devices connected to serial buses com- 
monly own resources of the serial buses and, in order 
that terminal devices, etc., transmit and/or receive pack- 
ets, the terminal devices, etc., occupy available 
resources. The resources occupied by the terminal 
devices, etc., can not be gotten by other terminal 
devices, etc., at the same time. Therefore, there may be 
a case where the other terminal devices, etc., can not 
acquire necessary resources and the terminal devices, 
etc., which failed to acquire the resources necessary to 
perform the packet transmission can not perform packet 
transmission. Incidentally, the previously mentioned 
P 1394.1 does not show any method of communication 
in the bridge. That is, a concrete resource managing 
method including the acquiring of resources in the 
bridge is not standardized as yet. 
[0027] A fourth problem is that the above mentioned 
network has no function of transferring packet between 
independently existing different serial buses through the 
bridge. That is, PI 394.1 discloses the input and/or out- 
put method of packets by means of the portals, while it 
does not disclose the packet communication method 
within the bridge. Therefore, the above network cannot 
transfer packets through the bridge by the method 
shown in PI 394.1. 

SUMMARY OF THE INVENTION 

[0028] An object of the present invention is to provide 
a bridge, particularly, an IEEE 1394 bridge, capable of 
improving the utilizing efficiency of bus by performing an 
initialization of network and a re-definition of topology 
while avoiding a reduction of a bus utilizing efficiency, 
when an insertion and/or removal of an active tine within 
a serial bus network occurs. 

[0029] That is, a bridge of the present invention is con- 
structed with a plurality of portals connected to individ- 
ual local buses, specifically, IEEE 1394 serial buses, 



connected to respective external terminal devices and 
internal buses connecting the portals mutually and ts 
featured by that each of the portals comprises topology 
information memory means for storing a topology infor- 

5 mation indicative of the local buses to which the termi- 
nal devices are connected, asynchronous packet 
receiving means for receiving, through the internal 
buses, asynchronous packets sent from the terminal 
devices and the portals connected to each other 

10 through same ones of the local buses and asynchro- 
nous packet discriminator means for judging, on the 
basis of a destination described in the asynchronous 
packet received by the asynchronous packet receiving 
means and the topology information stored in the topol- 

fs ogy information memory means, the local bus con- 
nected to the destination and, when a result of the 
judgement indicates that the local bus is different from 
that to which the portal is connected, for transmitting an 
asynchronous packet to the portal connected to the 

20 local bus and, when the result of the judgement indi- 
cates that the local bus is the same as that to which the 
portal is connected, for transmitting an asynchronous 
packet to the local bus to which the portal is connected. 
[0030] By constructing a network for the asynchro- 

25 nous transmission by connecting the mutually inde- 
pendent local buses to the respective portals of such 
bridge, an exchange of asynchronous packets is per- 
formed between terminal devices connected to the 
mutually different local buses. 

30 [0031] It is preferable that the IEEE 1 394 serial bijs be 
used as the-jAl bus and the bridge of the present 
invention be4HyEal as the IEEE 1394 bridge. In such 
case, by constHbtf'ng a serial bus network by connect- 
ing the mutually independent IEEE 1394 serial buses to 

35 the respective portals, an exchange of asynchronous 
packets between terminal devices connected to the 
mutually different IEEE 1394 serial buses occurs. In this 
' serial bus networK since the IEEE 1394 serial buses 
are mutually independent, 63 terminal devices at maxi- 

40 mum can be connected to each of the IEEE 1394 serial 
buses and, therefore, the number of terminal devices 
which can be connected to the serial bus network is not 
limited to 63. 

[0032] The topology information memory means may 
45 comprise topology re-definition means for detecting a 
change of the number of the terminal devices con- 
nected to the local buses connected to the portals to 
which the topology information memory mean belongs, 
specifying the terminal devices connected to the local 
so bus after the change of the number of terminal devices 
is detected and supplying an information indicative of 
the specified terminal devices to other portals and topol- 
ogy information update means for producing a new 
topology by combining the information supplied from the 
55 topology re-definition means of the other portals and the 
topology information stored by the topology information 
memory means and storing the new topology informa- 
tion. 
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[0033] Thus, when the number of terminal devices 
connected to each of the local buses is changed, the 
portal connected to the same local bus specifies termi- 
nal devices connected to the local bus after the change 
of the number of terminal devices. The information 
indicative of the newly specified terminal devices is sup- 
plied to the respective portals which produce new topol- 
ogy information by combining the supplied information 
and the topology information stored in the respective 
portals. Therefore, even when the number of terminal 
devices connected to any local bus is changed, the ini- 
tialization is performed for not the whole network but the 
same local bus, so that there is no need of stopping the 
packet exchange in the whole network. 
[0034] Further, the bridge may comprise internal bus 
resource managing means for receiving the asynchro- 
nous transmission packet for requesting a security of an 
isochronous transmission channel for an isochronous 
transmission of packet and securing the isochronous 
transmission channel on the internal bus and each por- 
tal may comprise local bus resource managing means 
for receiving the asynchronous transmission packet for 
requesting a security of an isochronous transmission 
channel for an isochronous transmission of packet and 
securing the isochronous transmission channel on the 
local bus connected thereto and channel control means 
for assigning an input port for receiving the isochronous 
transmission packet through the isochronous transmis- 
sion channel assigned as a transmitting side or a source 
of an isodironous transmission packet transmitted by 
the isochronous transmission, an output port for acquir- 
ing the isochronous transmission packet from the input 
port assigned as the source of the isochronous trans- 
mission packet and sending the isochronous transmis- 
sion packet to the isochronous transmission channel 
assigned as a destination side of the isochronous trans- 
mission packet, the isochronous transmission channel 
which is the originator side of the isochronous transmis- 
sion packet to the input port, the input port which is the 
source side of the isochronous transmission packet to 
the output port and the isochronous transmission chan- 
nel which is the destination side to which the output port 
supplies the isochronous transmission packet. 
[0035] The network composed of such txidge and the 
mutually independent local buses connected to the 
respective portals of the bridge performs an exchange 
of isochronous transmission packet (isochronous 
packet) between terminal devices connected to mutu- 
ally different local buses. 

[0036] Further, each of the portals of such bridge per- 
forms a management of the isochronous transmission 
resources of the local bus connected to the portal inde- 
perKlently from other portals. The management may 
include a processing for determining parameters such 
as isochronous transmission channel and its bandwidth, 
etc., which can be secured on the local txjses. for spec- 
ifying the isochronous channels and a processing for 
assigning the control right of isochronous transmission 



channel to the terminal device, etc., which requests the 
security of the isochronous transmission channel. 
Therefore, a local bus which has no relation to the 
exchange of isochronous transmission packet is free 

5 from an influence of the isochronous transmission 
packet exchange, for example, free from such as reduc- 
tion of transmission efficiency of other packets, so that 
the isochronous transmission resource of the local bus 
can be utilized efficiently. 

10 [0037] Assuming that at least one of the portals com- 
prises the internal bus resource managing means, there 
is no need of constituting the internal bus resource man- 
aging means by a separate device and, therefore, the 
structure of this bridge becomes simple and the manu- 

15 facture of the bridge and the management of the net- 
work including this bridge is facilitated. 
[0038] Each portal is connected to the internal bus 
resource managing means through, for example, the 
internal buses. 

20 [0039] Assuming that each portal and the internal bus 
resource managing means are connected to each other 
through the internal buses such that they constitute a 
chain without branch, the necessity of changing the 
internal bus resource managing means when new por- 

25 tals are added to the bridge or some of the existing por- 
tals are removed is avoided and the addition and/or 
removal of portals is facilitated. Therefore, the manage- 
ment of the network including the bridge is also facili- 
tated. 

30 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0040] Preferred embodiments of the present inven- 
tion will be described with reference to the accompany- 
35 ing drawings, in which: 

Rg. 1 shows an example of a conventional network 

using IEEE 1394 serial bus; 

Rg. 2 shows a format of a conventional asynchro- 

40 nous packet used in a quadlet read transaction; 

Rg. 3 shows a format of a conventional asynchro- 
nous packet used in a lock transaction; 
Rg. 4 shows schematically a conventional bridge 
shown by PI 394.1 Draft Standard 0.02; 

45 ' Rg. 5 is a block diagram of a bridge according to a 
first embodiment of the present invention; 
Rg. 6 is a detailed block diagram of a portion of the 
bridge shown in Fig. 5; 

Rg. 7 shows an example of a serial bus network 
50 constructed by connecting independent local buses 
by means of the IEEE 1394 bridge shown in Fig. 5; 
Rg. 8 is a block diagram illustrating operations of 
respective portions of the serial bus network shown 
in Fig. 7 when the serial bus network is initialized; 
55 Rg. 9 is a block diagram illustrating operation of the 
respective portions of the serial bus network shown 
in Fig. 7 when an initialization and re-definition of 
local buses are performed; 
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Fig. 10 is a format of an asynchronous packet 
defined by the IEEE 1394.1995; 
Fig. 1 1 shows an example of a serial bus network 
using the IEEE 1394 bridge; 

Fig. 12 is a block diagram illustrating operations of s 
respective portions of the serial bus network shown 
in Fig, 11 when a terminal device sends the asyn- 
chronous packet; 

Fig, 13 is a block diagram illustrating operations of 
the respective portions of the serial bus network io 
shown in Fig. 11 when a portal receives the asyn- 
chronous packet sent by the terminal device; 
Fig. 14 is a block diagram illustrating operations of 
the respective portions of the serial bus network 
shown in Fig. 1 1 when a portal sends the asynchro- 75 
nous packet onto a bridge bus; 
Fig. 15 is a block diagram illustrating operations of 
the respective portions of the serial bus network 
shown in Fig. 1 1 in a case where a value of a portal 
control register is 0 when the portal receives the so 
asynchronous packet from the bridge bus; 
Fig. 16 is a block diagram illustrating operations of 
the respective portions of the serial bus network 
shown in Fig. 1 1 in a case where a value of a portal 
control register is not 0 when the portal receives the 25 
asynchronous packet from the bridge bus; 
Fig. 17 is a block diagram illustrating operations of 
the respective portions of the serial bus network 
shown in Fig. 1 1 when the terminal device receives 
the asynchronous packet; 30 
Fig. 18 is a block diagram Illustrating operations of 
the respective portions of the serial bus network 
shown in Fig. 1 1 when the portal acquires a trans- 
mission permission from a bridge manager; 
Fig. 19 is a block diagram illustrating operations of 35 
the respective portions of the serial bus network 
shown in Fig. 1 1 in a case where the value of the 
portal control register is 0 when the portal receives 
an asynchronous packet (no data); 
Rg. 20 is a block diagram illustrating operations of 40 
the respective portions of the serial bus network 
shown in Fig. 1 1 in a case where the value of the 
portal control register is not 0 when the portal 
receives an asynchronous packet (no data); 
Fig. 21 is a block diagram illustrating operations of 4S 
the respective portions of the serial bus network 
shown in Fig. 1 1 when the terminal device receives 
an asynchronous packet (no data); 
Fig. 22 is a block diagram illustrating operations of 
the respective portions of the serial bus network so 
shown in Fig. 1 1 when the terminal device inquires 
a portal an isochronous resource; 
Fig. 23 is a block diagram illustrating operations of 
the respective portions of the serial bus network 
shown in Fig. 1 1 when the terminal device inquires ss 
an isochronous resource information of the local 
bus and the bridge bus; 

Fig. 24 is a block diagram illustrating operations of 



the respective portions of the serial bus network 
shown in Fig. 1 1 when the terminal device acquires 
an isochronous resource of the local bus and the 
bridge bus; 

Rg. 25 Is a block diagram illustrating operations of 
the respective portions of the serial bus network 
shown in Fig. 1 1 when a plug of a portal is related 
to an isochronous channel on a bus held for the ter- 
minal device; 

Rg. 26 shows a concrete flow of the isochronous 
packet; 

Fig. 27 is a block diagram illustrating operations of 
the respective portions of the serial bus network 
shown in Fig. 1 1 when the terminal device inquires 
a resource; 

Rg. 28 is a block diagram illustrating operations of 
the respective portions of the serial bus network 
shown in Fig. 1 1 when the portal receives an asyn- 
chronous packet from the terminal device; 
Rg. 29 is a block diagram illustrating operations of 
the respective portions of the serial bus network 
shown in Fig. 1 1 when an isochronous resource is 
acquired for the terminal device; 
Fig. 30 is a block diagram illustrating operations of 
the respective portions of the serial bus network 
shown in Fig. 11 when the portal acquires the iso- 
chronous resource of the bridge bus and the local 
bus; 

Fig. 31 is a block diagram illustrating operations of 
the respective portions of the serial bus network 
shown in Fig. 11 when a isochronous channel is 
related to the plug of the portal; 
Rg. 32 is a block diagram illustrating operations of 
the respective portions of the serial bus network 
shown in Fig. 1 1 when the portal makes Input/out- 
put plugs related mutually; 
Rg. 33 shows a concrete flow of the isochronous 
packet; and 

Rg. 34 is a block diagram of a bridge according to a 
second.embodiment of the present invention. 

DETAILED DESCRIPTION OF THE PREFERRED 
EMBODIMENTS 

< First EmtDodiment ) 

[0041] Fig. 5 is a block diagram showing an IEEE 
1394 bridge according to a first embodiment of the 
present invention. As shown in Fig. 5, the IEEE 1394 
bridge 11 is constructed with a plurality of portals 12a to 
12n, bridge buses 13 and a bridge manager 15. 
[0042] The portals 12a to 12n function as terminal 
devices connected to a plurality of local buses 14a to 
14n, respectively The portals 12a to 12n are star-con- 
nected to the bridge manager 15 through respective 
bridge buses 13 which are internal buses of the IEEE 
1394 bridge 11 so that the portals can communicate 
with each other. 



6 



.ISDOCID: <BP 0e33900A2J_> 



11 



EP 0 933 900 A2 



12 



[0043] The bridge bus 13 comprises an IEEE 1394 
serial bus similar to that constituting the local bus. The 
bridge manager 15 functions as an isochronous 
resource manager (IRM) which manages a communica- 
tion procedure on the bridge bus 13 and isochronous 5 
resources, that is, an isochronous channel for an iso- 
chronous transmission and a bandwidth to be used in 
that channel. The bridge manager 15 further performs a 
route function for sending a packet onto the bridge bus 
13 with a constant time interval. This packet is trans- to 
ferred. as a cyde start packet, from the portals i2a to 
12n which receive the packet to the local buses 14a to 
1 4n. The cycle start packet is used to determine an iso- 
chronous data transmission timing of a terminal device 
which acquires the isochronous resources of the local 75 
buses 1 4a to 1 4n. 

[0044] Fig. 6 is a block diagram of the portal 12a. It 
should be noted that the other portals 12b to 12n have 
substantially the same construction as that of the portal 
12a. 20 
[0045] As shown In Fig. 6, the porta! 12a is con- 
structed with a portal control register 22, a 
BANDWIDTH^AVAILABLE register 23, a 
CHANNEL.AVAILABLE register 24. a 
CHANNEL_SWITCH register 25, input plug control reg- 25 
isters (iPCR's) 26a to 26n and 28a to 28n, output plug 
control registers (oPCR's) 27a to 27n and 29a to 29n, 
input plug's (iPlug*s) 210a to 210n and 212a to 212n. 
output plug's (oPIug's) 21 la to 21 In and 213a to 213n, 
a memory 214, an asynchronous packet discriminator 30 
215 and a NODEJDS register 216. 
[0046] The portal control register 22 stores an infor- 
mation indicative of states of the bridge bus 13 and the 
local bus 14 to which the portal control register 22 is 
connected, that is, the local bus 14a for the portal con- 3s 
trol register 22 of the portal 12a. In concrete, the value 
of the portal control register 22 being 0 indicates that 
the local bus 14a and the bridge bus 13 are inltiatized as 
to be described later, in which case the portal 12a does 
not transfer any packet. On the other hand, when the 40 
value of the portal control register 22 is net 0, the portal 
12a assumes a state in which the packet received 
thereby can be transferred. 

[0047] The memory 214 stores a packet among the 
asynchronous packets received from the bridge bus 13 45 
and the local bus to which the memory 214 is con- 
nected, which is to be transferred to another portal. 
[0048] The asynchronous packet discriminator 215 
discriminates whether or not the received packet is 
transferred by referencing a destination_^ID field in a so 
header of the asynchronous packet received from the 
local bus connected to the bridge bus 13 and the asyn- 
chronous packet discriminator 215. Further, the asyn- 
chronous packet discriminator 215 discriminates 
whether or not the received asynchronous packet is to ss 
inquire bus resources for a portal to which other local 
buses are connected, on the basis of a content of a 
destination_offset field contained in the received asyn- 



chronous packet and the result of discrimination of the 
destination_ID field. Further, the asynchronous packet 
discriminator 215 determines whether or not the 
received packet is to acquire the isochronous 
resources, on the basis of an extended_tcode field con- 
tained in the received asynchronous packet. 
[0049] The NODEJDS register 216 stores an infor- 
mation for discriminating the respective terminal 
devices connected to the serial bus network, that is, for 
example, the network constituted with the IEEE 1394 
bridge 1 1 , the local buses 14a to I4n and the terminal 
devices connected to the local buses 14a to 14n. 
[0050] The iPlug's 210a to 210n and 212a to 2l2n and 
the oPIug's 211a to 21 In and 213a to 213n are related 
to specific isochronous data transfer channels secured 
on the bridge bus 13 and the respective local buses 14a 
to 14n by the terminal devices, etc., as to be described 
later. The portal 12a performed the input/output of iso- 
chronous data as to be described later. 
[0051] The iPCR 26a to 26n and 28a to 28n and the 
oPCR 27a to 27n and 29a to 29n store information 
Indicative of channels on the local buses 14a to 14n or 
the bridge bus 1 3 to which the respective i Plug's and the 
respective oPIug's are to be associated or correlated. 
[0052] The CHANNEL_SWITCH register 25 stores an 
Information indicative of a correlation of plugs on the 
side of the bridge bus, that is, the respective iPlug's and 
the respective oPIug's correlated to the channels 
secured on the bridge bus 13, plugs on the side of the 
local buses, that Is, the respective i Plug's and the 
respective oPIug's correlated to the channels secured 
on the local buses to which the CHANNEL_SWITCH 
register 25 are connected. 

[0053] In order to transmit isochronous data, the por- 
tal 12a correlates the respective iPlug's or oPIug's on 
the side of the local bus to the respective oPIug's or 
IPlug's on the side of the bridge bus according to the 
content of the CHANNEL_SWITGH register 25. 
[0054] The BANDW1DTH_AVA1LABLE register 23 and 
the CHANNEL_AVAILABLE register 24 store an infor- 
mation of available resources of the local bus to which 
these registers are connected. The information includes 
the bandwidth and the isochronous channels. The ter- 
minal device which transmits the isochronous packet 
confirms and acquires the resources by referencing 
these registers. 

[0055] Further, the portal 12a receives packets trans- 
mitted through the local bus to which the portal 1 2a is 
connected and packets transmitted through the bridge 
txis 13. When the value of the portal control register 22 
of the portal 12a is not 0, the portal 1 2a always transfers 
the cycle start packet which is transmitted by the bridge 
manager 15 onto the bridge bus 13 with a constant time 
interval to the local bus to which the portal 12a is con- 
nected. 
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[Operation] 

[0056] Operation of the portal 12a shown in Rg. 6, 
particularly, the initialization of the serial bus network, 
the re-definition of topology and the packet transfer, will 
be described with reference to Figs. 7 to 9. It should be 
noted that operations of other portals 12b to 12n are 
substantially the same as that of the portal 12a. 
[0057] Fig. 7 shows an example of the serial bus net- 
work constituted with the IEEE 1 394 bridge 1 1 , the local 
buses 14a to I4n and the terminal devices connected to 
the local buses 1 4a to 1 4n. 

[Initialization of the Serial Bus Network and Definition of 
Topology] 

[0058] In order to perform communication between 
terminal devices connected to different local buses in 
the, serial bus network shown in Fig. 7, the serial bus 
network is initialized and the topology is defined, that is, 
the bridge bus and the local buses contained in the 
serial bus network and the portals and the terminal 
devices connected to these buses are specified. The ini- 
tialization of the serial bus network and the definition of 
the topology will be described. 
[0059] Fig. 8 shows a flow of commands when the 
serial bus network is initialised. 
[0060] In Fig. 8. the bridge manager (BM) 1 5 transmits 
a bridge bus initialization command 41 to the respective 
portals to start the initialization of the serial bus net- 
work. In response to the bridge bus initialization com- 
mand 41, the respective portals cancel packets stored 
in the memories 214 thereof and the contents of the 
NODEJDS registers 216 thereof set the values of the 
portal control registers 22 thereof to 0, so that the trans- 
fer of packets of the respective portals become substan- 
tially impossible. 

[0061] Then, the bridge manager 1 5 defines the topol- 
ogy on the bridge bus 13. After the bridge bus 13 is ini- 
tialized through the predetermined procedures, a 
tree_ID process is executed by the procedures defined 
by, for example, the IEEE 1394.1995 Appendix E.3.2. to 
define topology of the respective portals on the bridge 
bus 13. The bridge manager 15 sends a transmission 
permission to the portals whose topology on the bridge 
bus 13 is defined. 

[0062] The portal which receives the transmission per- 
mission from the bridge manager 15 transmits a self^lD 
packet to the bridge manager 1 5. The bridge manager 
15 assigns a portal_ID to the portal to which the bridge 
manager 15 sent the self^lD. The procedure for deter- 
mining the portaMD is substantially the same as the 
procedure for determining the node_ID described in, for 
example, the IEEE 1394.1995 Appendix E.3.3. 
[0063] When the portaLID is assigned to the respec- 
tive portals 12a to 12n, the initialization of the local 
buses 14a to 14n and the definition of topology are per- 
formed. 



[0064] Fig. 9 shows a flow of commands when the ini- 
tialisation of the local buses 14 and the redefinition of 
topology are performed. 

[0065] When the portaLID is assigned to each of the 

5 portals 12a to 12n, the bridge manager 15 sends the 
local bus initialization command 41 to the bridge bus 1 3. 
In response to the local bus initialization command 41 , 
the portals 12a to 12n initialize the respective local 
buses by sending a bus reset signal 52 to the local 

10 buses to which the portals are connected, respectively 
[0066] The portals 12a to 12n define (or redefine) 
topology of the local buses to which the portals are con- 
nected, respectively, according to the procedure defined 
by, for example, the IEEE 1394.1995. In this case, the 

15 bus_ID of each of the local buses is assigned such that 
it coincides with the portal_ID assigned to the portal 
which is connected to a corresponding one of the local 
buses. Further, in defining topology, each of the portals 
12a to 12n assigns itself to a route and an IRM of the 

20 corresponding local bus to which the portal is con- 
nected. 

[0067] The NODEJDS register 216 of each of the por- 
tals 12a to 12n stores an information for identifying the 
terminal device connected to the local bus to which the 
25 portal is connected. Thus, the portals 12a to 12n com- 
plete the initialization and definition of topology of the 
local buses 14a to 14n. 

[0068] When the initialization of the local buses 13 to 
which the respective portals 12a to 12n are connected 

30 and the definition of topology thereof are completed, the 
portals 12a to 12n transmit the contents of their 
NODEJDS registers 216 to the bridge manager 15. 
After the bridge manager 15 receives the contents of 
the NODE_IDS registers 216 of the respective portals 

35 12a to 12n, the bridge manager 15 combines the con- 
tents and rewrites the contents of the NODE_IDS regis- 
ters 216 with an information obtained by the 
combination, that is, an information identifying the termi- 
nal devices connected to the serial bus network. In con- 

40 aete, the . bridge manager 15 performs a write ' 
transaction for writing the information in the NODEJDS 
registers 216 of the respective portals 12a to 12n 
according to the procedure defined by for exanple, the 
IEEE 1394.1995. 

45 [0069] Thereafter, the portals 12a to 12n set the val- 
ues of the portal control registers 22 thereof to 0 so that 
their packet transfers become possible. 
[0070] in the serial bus network, there is a case where 
a new terminal device is connected to any one of the 

so local buses 14a to 14n or the terminal device is discon- 
nected from one of the local buses 14a to 14n. When 
such state change occurs in any of the local buses 14a 
to 1 4n, the local bus in which the state change occurs is 
initialized by the portal connected thereto and the topol- 

55 ogy thereof is redefined by the portal. In this case, the 
portal sets the value of its own portal control register 22 
to 0, so that the portal assumes a state in which a 
packet transfer between the local bus and the bridge 



8 



<EP 0933900A2J_> 



15 



EP 0 933 900 A2 



16 



bus 13 to which the portal is connected becomes sub- 
stantially impossible. 

[0071] After the redefinition of topology is completed, 
the portal transmits the content of the NODE_IDS regis- 
ter 216 thereof to the bridge manager 15. In response to 
the content of the NODE^IDS register 21 6 of the portal, 
the bridge manager 15 rewrites the previous contents of 
the NODE_IDS registers of the portals 12a to 12n such 
that they contain the contents of the NODE_IDS register 
216 of the portal which performed the re-definition of 
topology, respectively 

[Packet Transfer] 

[0072] After the initialization of the serial txis network 
and the definition of topology are completed, an 
exchange of asynchronous packets and isochronous 
packets between the terminal devices connected to the 
serial bus network becomes possible. 
[0073] In a case where a terminal device transmits an 
asynchronous packet, the terminal device requests a 
porta! which is a route of a local bus to which the termi- 
nal device is connected to a right of control of the same 
local bus. The portal gives the terminal device the local 
bus control right regardless of the state of the bridge 
bus 13 and local buses other than that to which the por- 
tal is connected. The terminal device which obtained the 
local bus control right transmits an asynchronous 
packet to the same local bus. 

[0074] When the destination of the asynchronous 
packet thus transmitted is a terminal device which is 
connected to the same local bus as that to which the 
asynchronous packet originator terminal device, other 
portals which are connected to the local bus do not par- 
ticipate in the asynchronous packet transfer. On the 
contrary, when the destination of the asynchronous 
packet is a terminal device connected to another local 
bus, a portal connected to the same local bus as that to 
which the packet originator terminal device is connected 
transfers the asynchronous packet to the destination 
through the bridge bus 1 3. 

[0075] The communication procedure of an asynchro- 
nous packet between terminal devices connected to dif- 
ferent local buses in the serial bus network will be 
described with reference to Figs. 10 to 21 . 

[Communication Procedure of Asynchronous Packet] 

[0076] Fig. 1 0 shows an example of a packet format of 
the asynchronous packet. The packet format shown in 
Fig. 10 is substantially the same as the packet format 
defined by the IEEE 1394.1995, 
[0077] At a head of the asynchronous packet having 
the fornnat shown in Fig. 10, there is a data region 61 
called destinationJD field. A busJD and a nodeJD of 
a source terminal device are described in this data 
region and the source terminal device can be identified 
by the bus_ID and the nodeJD. Further, in a source_ID 



field 62 which is a data region succeeding the 
destination_ID field 61 , an information for identifying the 
asynchronous packet source terminal device is 
described. 

[0078] Further, the asynchronous packet has a 
destination_offset field which is not shown in Fig. 10. In 
this destination_offset field, information indicative of 
whether the asynchronous packet is transmitted in order 
to acquire the values stored in the 
BANDWIDTH_AVAILABLE register 23 and the 
CHANNEL_AVAILABLE register 24 is described. 
[0079] Further, the asynchronous packet has an 
extended_tcode field which is not shown in Fig. 10. In 
the extended_tcode field, information indicative of 
whether the asynchronous packet is transmitted in order 
to perform the compare and swap operation for the 
BANDWIDTH_AVAILABLE register 23 and the 
CHANNEL_AVAILABLE register 24 is described. 
[0080] Fig. 11 shows an example of a serial bus net- 
work constructed with an IEEE 1394 bridge 11 com- 
posed of a bridge manager 15 and two portals 12a and 
12b, a terminal device 31a connected to the portal 12a 
through a local bus and a terminal device 31b con- 
nected to the portal 12b through a local bus. The IEEE 
1394 bridge 1 1 , the portals 1 2a and 12b and the bridge 
manager 15 of the serial bus network shown in Fig. 1 1 
are substantially the same as those deleted by the 
same reference numerals in Fig. 1. 
[0081] Now, the procedure for transmitting an asyn- 
chronous packet from the terminal device 31a to the ter- 
minal device 31b will be described with reference to Fig. 
11' 

[0082] Fig. 1 2 shows operations of respective portions 
of the serial bus network shown in Fig. 1 1 when the ter- 
minal device 31 a of the serial bus network transmits the 
asynchronous packet. 
[0083] As shown in Fig. 12, 

(1 ) the terminal device 31a transmits a transmission 
request 81 to the portal 12a according to the proce- 
dure defined by, for example, the IEEE 1394.1995, 
and 

(2) the portal 1 2a which receives the transmission 
request 81 transmits a transmission permission 82 
to the terminal device 31a and the terminal device 
31a which receives the transmission permission 82 
transmits the asynchronous packet to a local bus. 

Fig. 13 shows operations of respective portions 
of the serial bus network shown in Fig. 11 when the 
portal 12a receives the asynchronous packet 91 
transmitted by the terminal device 31a of the serial 
bus network. 

As shown in Fig. 13. 

(3) the asynchronous packet discriminator 215 of 
the portal 12a reads the bus„tD of the destination 
described in the destination_lD field 61 of the 
received asynchronous packet 91 , and 

(4) when the bus_ID read in (3) is different from the 
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bus_ID of the local bus 1 4a connected to the portal 
12a or indicates that the packet is a multi address 
packet, that is, the packet to be sent to all ternninal 
devices connected to the serial bus network (the 
bLis_ID is, for example, ^^SFF** in hexadecimal nota- 5 
tion which is the value defined by the IEEE 
1 394. 1 995) , the portal 1 2a transmits a transmission 
request 93 to the bridge manager 1 5 and stores the 
received asynchronous packet 91 in its memory 
214a. The memory 214a is substantially the same fo 
as the previously mentioned memory 214. 

The portal 1 2a transmits a transmission confir- 
mation signal 92b including, for example, a pending 
code defined by the IEEE 1394.1995 for confirming 
transmission of the transmission request to the is 
local bus 14a. 

Fig. 1 4 shows operations of respective portions 
of the serial bus network shown in Rg. 1 1 when the 
portal 12a transmits the asynchronous packet 91 to 
the bridge bus 1 3 of the serial bus network 20 

As shown in Fig. 14, 

(5) the bridge manager 1 5 which receives the trans- 
mission request 93 transmits a transmission per- 
mission 101 to the portal 12a, and 

(6) the portal 12a which receives the transmission 25 
permission 101 from the bridge manager 15 trans- 
mits the asynchronous packet 91 stored in the 
memory 214a to the bridge bus 13. The portal 12b 
receives the asynchronous packet 91 transmitted 

by the portal 1 2a, from the bridge bus 1 3. The asyn- so 
chronous packet discriminator 215b of the portal 
12b reads the content of a destination_bus„ID field 
61 of the received asynchronous packet 91 and, 
when the bus_ID described in the 
destination_bus_ID field 61 substantially coincides 35 
with the bus_ID of the local bus 14b connected to 
the portal 12b or indicates that the received asyn- 
chronous packet 91 is a multi address packet, the 
received asynchronous packet 91 is stored in the 
memory 2 1 4b of the portal 1 2b. 40 

Figs. 15 and 16 show operations of respective 
portions of the serial txjs network shown in Fig. 1 1 
when the portal 12b receives the asynchronous 
packet 91 from the bridge bus 13 of the serial bus 
network. 4s 

As shown in Figs. 15 and 16, 

(7) when the portal 12b confirms that the bus_lD 
which substantially coincides with Itie bus_ID of the 
local bus 14b receives the asynchronous packet 91 
described in the destination_busJD field 61, the -so 
portal 12b reads the value of the portal control reg- 
ister 22b thereof. 

Then, as shown in Fig. 15, 
(8-a) when the value of the portal control register 
22b of the portal 1 2b is 0, the portal 1 2b transmits a ss 
transmission confirmation signal 111a for confirm- 
ing the transmission of the asynchronous packet 
91, including, for exannple, an address error code 



defined by the IEEE 1394. 1995 to the bridge bus 13 
and cancels the packet stored in the memory 214b 
thereof, (9-a) the portal 12a which receives the 
transmission confirmation signal 111a from the 
bridge bus 13 cancels the asynchronous packet 91 
stored in the memory 214a thereof and transmits a 
transmission confirmation signal 1 12 for confirming 
the transmission of the synchronous packet 91, 
including, for example, an address error code 
defined by the IEEE 1394.1995 to the local bus 
14a. . 

The terminal device 31a which receives the 
transmission confirmation signal 112 repeats the 
transmission procedure of the asynchronous 
packet 91 is repeated from the procedure (1). 

On the other hand, as shown in Fig. 16, 
(8-b) when the value of the portal control register 
22b of the portal 12b is not 0, the portal 12b trans- 
mits the asynchronous packet 91 stored in the 
memory 214b to the local bus 14b. and 
(9-b) the portal 12b transmits a transmission confir- 
mation signal 111b including the pending code 
indicative of a continuation of the transmission pro- 
cedure to the bridge bus 13. The portal 12a which 
receives the transmission confirmation signal 111b 
from the portal 12b cancels the asynchronous 
packet 91 stored in the memory 214a thereof. 

Fig. 17 shows operations of respective portions 
of the serial bus network shown in Fig. 1 1 when the 
terminal device 31b receives the asynchronous 
packet 91 from the bridge bus 13 of the serial bus 
network. 

As shown in Fig. 17, 

(10) when the terminal device 31b receives the 
asynchronous packet 91 sent thereto, the terminal 
device 31b transmits a transmission confirmation 
signal 121 to the local bus 14b. arKl 

(11) the portal 12b which receives the transmission 
confirmation signal 121 from the terminal device 
31b, the portal 12b transmits a transmission 
request 122 to the bridge manager 15. 

Fig. 18 shows operations of respective portions 
of the serial bus network shown in Fig. 1 1 when the 
portal 12b obtains a transmission permission 131 
from the bridge manager 15 in the serial bus net- 
work. 

As shown in Fig. 18, 

(12) the bridge manager 15 which receives the 
transmission request 122 from the portal 12b trans- 
mits a transmission permission 131 to the portal 
12b, and 

(1 3) the portal 12b which receives the transmission 
permission 131 from the bridge manager 15 reads 
the content, that is. an information identifying the 
transmitting side, of a source„ID field 62 contained 
in the asynchronous packet 91 stored in the mem- 
ory 214b thereof, produces an asynchronous 
packet (no data) 132 having a destination_ID field 



10 



4SDOCID: <EP 0933900A2J_> 



19 



EP 0 933 900 A2 



20 



61 in which the content of the thus read source_ID 
field 62 is described and transmits the asynchro- 
nous packet 132 to the bridge bus 13. Then, the 
portal 12b cancels the asynchronous packet 91 
stored in the memory 214b thereof and, instead 5 
thereof, stores the asynchronous packet (no data) 
132 in the memory 214b. 

Figs. 19 and 20 show operations of respective 
portions of the serial bus network shown in Fig. 1 1 
when the portal 12a receives the asynchronous 10 
packet (no data) 132 from the bridge bus 13 of the 
serial bus network. 

As shown in Figs. 19 and 20, 
(14) when the portal 12a receives the asynchro- 
nous packet (no data) 132 transmitted from the por- is 
tal 12b, the asynchronous packet discriminator 
215a of the portal 12a reads the content of the 
destination_ID field 61 of the asynchronous packet 
(no data) 132. When the value of the bus_ID con- 
tained in the thus read content coincides with the 20 
value indicated by the local bus 14a, the portal 12a 
stores the received asynchronous packet (no data) 
132 in its memory 214a. Thereafter, the portal 12a 
reads the value stored in the portal control register 
22a and decides whether or not its value is 0. 2S 

And, as shown in Fig. 19. 
(15-a) when the value stored in the portal control 
register 22a is 0, the portal 12a sends a transmis- 
sion confirmation signal 142 including a rewrite 
code to the bridge bus 13. After the portal 12b 30 
receives the transmission confirmation signal 142, 
transmits the transmission request to the bridge 
manager 15 and receives the transmission permis- 
sion from the bridge manager 15, the portal 12b 
sends the asynchronous packet (no data) 132 35 
stored in the memory 214b to the bridge manager 
13 again. 

Further, as shown in Fig. 20. 
(15-b) when the value stored in the portal control 
register 22a is not 0. the portal 12a sends the trans- 40 
mission confirmation signal 141 to the bridge bus 
13 and sends the asynchronous packet (no data) 
132 stored in the memory 214a to the local bus 
14a. The portal 12b receives the transmission con- 
firmation signal 141 and cancels the asynchronous 4S 
packet (no data) 132 stored in the memory 214b. 

Fig. 21 shows operations of respective portions 
of the serial bus network shown In Fig. 11 when the 
terminal device 31a receives the asynchronous 
packet (no data) 132 from the bridge bus 13 of the so 
serial bus network. 

As shown in Fig. 21. 
(16) when the terminal device 31a receives the 
asynchronous packet (no data) 1 32 sent by the por- 
tal 12a, the terminal device 31a sends a transmis- ss 
sion confirmation signal 151 to the local bus 14a. 
When the portal 12a receives the transmission con- 
firmation signal 151. it cancels the asynchronous 



packet (no data) 132 stored in the memory 214a. 

The communication procedures are completed 
through the above mentioned steps (1) to (16) and 
the asynchronous packet Is transmitted from the 
terminal device 31a through the IEEE 1394 bridge 
1 1 to the terminal bridge 31b. 

[Isochronous Packet Communication Procedures] 

[0084] After the initialization of the serial bus network 
and the definition of topology are completed, it becomes 
possible to exchange not only asynchronous but also 
isochronous packets between the terminal devices con- 
nected to the serial bus network. 
[0085] A terminal device which is trying to send an iso- 
chronous packet on a local bus to which it is connected 
requests a portal which is the IRM of the local bus an 
isochronous resource. The isochronous resource man- 
agement of the serial bus network is performed for 
every local bus by the portal which is the IRM of the 
local bus. That is, a state of resource of one local bus is 
not influenced by states of resources of other local 
buses. 

[0086] When an isochronous communication is per- 
formed between terminal devices connected to different 
local buses, the isochronous packet is transferred 
between portals connected to the local buses to which 
the terminal devices are connected, through the bridge 
bus. 

[0087] As to the transfer of isochronous packets, the 
following two cases are considered: 

(Case 1) Isochronous resources for a terminal 
device are already secured on a local bus, the ter- 
minal device is transmitting an isochronous packet 
and a terminal device connected to a local bus dif- 
ferent from that to which the terrninal device is con- 
nected receives the transmitted isochronous 
packet; and 

(Case 2) After a terminal device (source terminal) 
which tries a transmission of an isochronous packet 
to a terminal device (destination terminal) con- 
nected to a local bus different from that to which the 
source terminal device is connected decides the 
transmission of the packet, isochronous resources 
of the local buses to which the transmitting and 
receiving terminal devices are connected and the 
bridge bus are acquired. 

[0088] A communication procedure of an isochronous 
packet in the above mentioned case 1 will be described 
with reference to Figs. 22 to 33 by taking, as an exam- 
pie, a case where the terminal device 31b receives an 
isochronous packet transmitted by the terminal device 
31a under the condition that the terminal device 31a 
already acquired the isochronous resource on the local 
bus 14a, transmits the isochronous packet and is com- 
municating with the portal 12a in the serial bus network 
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shown in Fig. 1 1 . Incidentally, it is assumed that the ter- 
minal device 31a acquired the isochronous resource oh 
the local bus 14a according to the procedures defined 
by. for exannple. the IEEE 1394.1995. 
[0089] Fig. 22 shows operations of respective portions s 
of the serial bus network shown in Fig. 11 when the ter- 
minal device 31b inquires-the terminal device 31a of the 
bus resource which was secured on the local bus 1 4a 
by the terminal device 31a. 

[0090] As shown in Fig. 22, io 

(1) the terminal device 31b inquires from the termi- 
nal device 31a an information indicative of the iso- 
chronous resource acquired on the local bus by the 
terminal device 31a. by using an asynchronous is 
packet. 

In concrete, the terminal device 31b performs a 
read transaction (data read) 161 from the oPCR of 
the terminal device 3 1 a through the portals 1 2a and 
12b according to, for example, the procedures 20 
defined by the IEEE 1394.1995. The terminal 
device 31b receives a read response 162 from the 
terminal device 31a. The terminal device 31b 
acquires an information indicative of a channel 
occupied on the local bus 14a by the terminal 25 
device 31a and its bandwidth, that is. an information 
indicative of the isochronous resource, from the 
received read response 162. 

The read response 162 is transferred through 
the portals 12a and 12b to the terminal device 31b 30 
in the format of the asynchronous packet. When the 
portals 12a and 12b receive the packet, the asyn- 
chronous packet discriminators 21 5a and 215b dis- 
criminate the destination thereof by reading the 
content of the destinatlonJD field 61 of the packet 35 
and the portals 12a and 12b transfer the packet to 
the discriminated destination according to the 
above mentioned asynchronous packet communi- 
cation procedure. 

Fig. 23 shows operations of respective portions 40 
of the serial bus network shown in Fig. 1 1 when the 
terminal device 31b inquires from the portal 12b a 
resource information of the local bus 14b and the 
bridge bus 13. 

As shown in Fig. 23, 45 

(2) the terminal device 31b inquires from the portal 
1 2b which is the IRM of the local bus 1 4b an availa- 
ble isochronous resource oh the local bus 14b and 
inquires from the bridge manager 15 which is the 
IRM of the bridge bus 13 an available isochronous . so 
resource on the bridge bus 13. 

In concrete, the terminal device 31b performs a 
quadlet read transaction (data read) 171a with 
respect to the portal 12b by using the asyn- 
chronous packet and receives a read ss 
response 171b corrtaining the values of the 
BANDWIDTH_AVAILABLE register 23b and the 
CHANNEL_AVAILABLE register 24b of the portal 



12b, which are acquired by the read response 
171b. The terminal device 31b performs a quadlet 
read transaction 172a with respect to the bridge 
manager 15 by using the asynchronous packet and 
receives a read response 172b containing the val- 
ues of the BANDW1DTH_AVAII_ABLE register 23c 
and the CHANNEL.AVAILABLE register 24c of the 
bridge manager 1 5, which are acquired by the read 
response 172b. 

Fig. 24 shows operations of respective portions 
of the serial bus network shown in Fig. 1 1 when the 
terminal device 31b acquires the resource informa- 
tion on the local bus 1 4b and the bridge bus 1 3. 

As shown in Fig. 24, 
(3) the terminal device 31b compares the informa- 
tion which is obtained by the procedure (2) and 
indicative of the isochronous resources usable on 
the portal 12b and the bridge manager 15 with the 
information which is obtained by the procedure (1) 
and indicative of the isochronous resource secured 
on the local bus 1 4a by the terminal device 31a and 
determines whether or not the terminal device 31a 
can acquire an isochronous resource on the local 
bus 14b and the bridge bus 13. which is similar to 
the isochronous resource secured on the local bus 
14b by the terminal device 31a. 

When the terminal device 31b decides that the 
terminal device 31a can acquire an isochronous 
resource on the local bus 14b and the bridge bus 
13, which is similar to the isochronous resource 
secured on the local bus 14b by the terminal device 
31a, the terminal device 31b secures the iso- 
chronous resource by performing a lock transaction 
181a to the portal 12b which is the IRM of the local 
bus 14b. In concrete, the terminal device 31b oper- 
ates (compares & swaps) to update portions of the 
contents of the BANDWIDTH_AVAILABLE register 
23b and the CHANNEL_AVAILABLE register 24b 
which are different from the information indicative of 
the isochronous resource obtained by the proce- 
dure (1) by using the asynchronous packet, accord- 
ing to, for example, the procedures defined by the 
IEEE 1394.1995. 

Further, the terminal device 31b secures the 
isochronous resource by performing a lock transac- 
tion 182a with respect to the bridge manager 15 
which is the IRM of the bridge bus 13. In concrete, 
the terminal device 31b updates portions of the 
contents of the BANDW1DTH„AVAILABLE register 
23c and the CHANNEL_AVAILABLE register 24c, 
which are different from the information indicative of 
the isochronous resource obtained by the proce- 
dure (1), through a similar procedure to that in the 
lock transaction 181a. 

After the terminal device 31b secures the iso- 
chronous resource, the terminal device 31b 
receives lock responses 181b and 182b from the 
portal 12b and the bridge manager 15. 
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Incidentally, when it is judged that it is impossi- 
ble to secure a similar isochronous resource on the 
local bus 14b and the bridge bus 13 to that on the 
local bus 14a. the terminal device 31b does not 
request any isochronous resource. 

Fig. 25 shows operations of respective portions 
of the serial bus network shown in Fig. 1 1 when an 
isochronous channel secured by the terminal 
device 31b is to be associated with plugs of the por- 
tals 12a and 12b. 

As shown in Fig. 25. 

(4) the terminal device 31b performs a write trans- 
action (data write) 195a with respect to an oPCR 
191 b of the portal 12b on the side of the local bridge 
by using an asynchronous packet according to, for 
example, the procedure defined by the IEEE 
1394.1995, in order to associate the isochronous 
channel secured on the local bus 1 4b with an oPlug 
194b. 

Thereafter, when the terminal device 31b 
receives a whte response 1 96b from the portal 1 2b, 
the terminal device 31b further performs a write 
transaction 197a with respect to the 
CHANtslEL_SWrrCH register 25b of the portal 12b; 
in order to associate an iPlug 193b with an oPIug 
194b. 

(5) When the terminal device 31b receives a write 
response 197b from the portal 12b after the proce- 
dure (4), the terminal device 31b performs a write 
transaction 198a similar to the write transaction 
196a in the procedure (4) with respect to the portal 
12a. With this, the terminal device 31b mutually 
associates an iPlug .193a on the local bus side of 
the portal 12a with the isochronous channel 
secured on the local bus 14a by the terminal device 
31a. 

[0091 ] Further, in response to the write response 1 97b 
from the portal 12b, the terminal device 31b performs a 
write transaction 199a with respect to the portal 12a. 
With this write transaction, the terminal device 31b 
mutually associates an oPIug 194a of the portal 12a 
with the isochronous channel secured on the local bus 
14a by the terminal device 31b. 

[0092] Thereafter, in response to the write responses 
198b and 199b transmitted from the portal 12a in 
response to the write transactions 198a and 199a, the 
terminal device 31b performs a write transaction 1910a 
with respect to the CHANNEL_SWITCH register 25a of 
the portal 12a. With this transaction, the terminal device 
31b associates an.iPlug 193a with an oPIug 194a. 
[0093] After the terminal device 31b performs the write 
transaction 1910a. it receives a write response 1910b 
from the portal 12a. 

[0094] Through the above described procedures (1 ) to 
(5), the terminal device 31a can receive the isochronous 
packet sent from the terminal device 31a. 
[0095] Incidentally, in the procedure (1), it is unneces- 



sary for the terminal device 31b to inquire of the termi- 
nal device 31a the isochronous resource occupied on 
the local bus 14a by the terminal device 31a and the ter- 
minaldevice31bmay inquireoftheportal 12athiesame 
5 resource. 

[0096] Fig. 26 shows a concrete flow of an iso- 
chronous packet 191 1 in the serial bus network shown 
in Fig. 1 1 . 

[0097] As shown in Fig. 26. the bridge manager 15 

10 sends a cycle start packet 1912 to the bridge bus 13. 
The portal 1 2a receives the cycle start packet 1912 and 
transfers the latter to the local bus 14a. When the termi- 
nal device 31a receives the cycle start packet 1912 
transferred to the local bus 14a, the terminal device 31a 

15 sends the isochrorx)us packet 1 91 1 . Then, the portal 
12a receives the isochronous packet 191 1 sent onto the 
local bus 14a through the iPlug 193a, and the portal 12a 
sends the isochronous packet 1911 onto the iso- 
chronous channel secured on the bridge bus 13 through 

20 the bPlug 194a according to the content of the 
CHANNEL_SWITCH register 25a. 
[0098] The isochronous packet 1 91 1 sent to the same 
isochronous channel on the bridge bus 13 is received by 
the portal 12b through the iPlug 193b. The portal 12b 

25 sends the received isochronous packet 1 91 1 to the iso- 
chronous channel secured on the local bus 14b through 
the oPIug 194b according to the content of the 
CHANNEL_SWITCH register 25b. The terminal device 
31b receives the isochronous packet 1911 sent to the 

30 isochronous channel. 

[0099] Next, the communication procedure of the Iso- 
chronous packet in the previously mentioned case (2) 
when the terminal device 31a inquires of the portal 12b 
the isochronous resource will be described with refer- 

35 ence to Figs. 27 to 29. 

[0100] As shown in Fig. 27. 

(1) the terminal device 31a inquires from the porta! 
12a which is the IRM the local bus 14a to which the 

40 terrninal device 31a is connected an available iso- 
chronous resource, prior to a sending of the iso- 
chronous packet. 

In concrete, the terminal device 3 1 a performs a 
quadlet read transaction 201 similar to the above 

45 mentioned quadlet read transaction 171a with 
respect to the destination_ID field 61 by using, for 
example, an asynchronous packet describing the 
bus_lD and the nodeJD of the portal 12a- With this 
transaction, the terminal device 31a requests the 

50 portal 12a to return the values of the 
BANDWIDTH_AVAILABLE register 23a and the 
CHANNEL_AVAILABLE register 24a of the portal 
12a. 

Fig. 28 shows operations of respective portions 
55 of the serial bus network shown in Fig. 1 1 when the 
portal 12a receives the asynchronous packet trans- 
mitted from the terminal device 31a in the serial bus 
network shown in Fig. 1 1 . 
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As shown in Fig. 28, 

(2) assuming that the portal 1 2a receives the asyn- 
chronous packet transmitted by the terminal device 
31a, the asynchronous packet discriminator 215a 
determines whether or not the received asynchro- s 
nous packet is a packet for Inquiring of the portal 
12a the isochronous resource of the local bus 14b. 

in concrete, the asynchronous packet discrimi- 
nator 215a reads the content described in the 
destination_ID field 61 and the destination^offset io 
field of the received asynchronous packet and, from 
the content thus read, determines that the packet is 
the asynchronous packet for acquiring values to be 
stored in the BANDWIDTH_AVAILABLE register 
23a and the CHANNEL_AVAILABLE register 24a. is 

(3) After the discrimination is performed according . 
to procedure (2), the portal 12a returns the values 
stored in the BANDWIDTH_AVAILABLE register 
23a and the CHANNEL_AVAII_ABLE register 24a to 

the terminal device 31a as a read response 2103. so 

(4) Then, the portal 12a inquires from the bridge 
nranager 15 the isochronous resource of the bridge 
bus 13 and acquires an information indicative of the 
isochronous resource from the bridge manager 1 5. 
Further the portal 1 2a inquires of the portal 1 2b the 2S 
isochronous resource of the local bus 14b and 
acquires an information indicative of the iso- 
chronous resource from the portal 12b. The above 
inquiries to the bridge manager 15 and the portal 
12b are performed by performing quadlet read 30 
transactions 2101a and 2102a each similar to the 
previously mentioned quadlet read transaction 201 
with respect to the bridge manager 15 and the por- 
tal 1 2b. In this case, the information indicative of the 
isochronous resource is transmitted from the bridge 35 
manager 15 and the portal 12b as, for example, 
read responses 2101b and 2102b each having a 
similar format to the above mentioned read 
response 2103. 

Fig. 29 shows operations of respective portions 40 
of the serial txjs network shown in Rg. 1 1 when the 
terminal device 31a acquires the isochronous 
resource of the local bus 1 4a. 

As shown in Fig. 29, 

(5) the terminal device 31a performs a lock transac- 45 
tion 221 in a similar manner to that of, for example, 

the above mentioned lock transaction 181a, with 
respect to the portal 12a, by using the asynchro- 
nous packet. 

(6) When the portal 12a receives the packet trans- so 
mitted from the terminal device 31a, the asynchro- 
nous packet discriminator 215a reads the contents 

of the destination_ID field 61 and the 
extended_tcode field of the packet received by the 
portal 12a. and determines that the packet is to ss 
request the BANDWIDTH_AVAILABLE register 23a 
and the CHANNEL_AVAILABLE register 24a to 
perform the compare & swap operation. Then, the 



portal 12a performs the compare & swap operation 
for the BANDWIDTH_AVAII_ABLE register 23a and 
the CHANNEL_AVAILABLE register 24a. 

(7) Thereafter, the portal 12a transmits a transmis- 
sion confirmation signal 222 containing a pending 
code indicative of a continuation of the isochronous 
channel acquiring procedure to the local bus 14a. 

Fig. 30 shows operations of respective portions 
of the serial bus network shown in Fig. 1 1 when the 
portal 12a acquires the isochronous resources of 
the bridge bus 13 and the local bus 14b, 

As shown in Fig. 30, 

(8) the portal 12a performs a lock transaction 23 la 
with respect to the bridge manager 15 by using the 
asynchronous packet. That is, the portal 12a 
acquires the isochronous resource of the bridge 
manager 13 by causing the bridge manager 15 to 
perform the compare & swap operation with respect 
to the BANDWIDTH_AVAII_ABLE register 23c and 
the CHANNEL^AVAILABLE register 24c. Thereaf- 
ter, the portal 12a receives a lock response 231b 
from the bridge manager 15. 

Incidentally, among the secured isochronous 
resources, the bandwidth occupied on the bridge 
bus 13 by the portal 12a is substantially the same 
as the bandwidth occupied on the local bus 14a by 
the terminal device 31a. 

(9) Then, the portal 12a acquires the isochronous 
resource on the local bus 14b by performing a lock 
transaction 232a with respect to the 
BANDWIDTH_AVAILABLE register 23b and the 
CHANNEL_AVAILABLE register 24b of the portal 
12b. 

Among the secured isochronous resources, 
the bandwidth occupied on the local bus 1 4b by the 
portal 12b is the same as the bandwidth occupied 
on the local bus 14a by the terminal device 31a. 
Thereafter, the portal 12a receives a lock response 
232b from the portal 12b. 

Fig. 31 shows operations of respective portions 
of the serial bus network shown in Fig. 1 1 when the 
isochronous channels secured by the bridge bus 1 3 
and the local buses 14a and 14b are to be associ- 
ated v^rith the plugs of the portals 12a and 12b. 

As shown in Fig. 31 , 

(10) the porta! 12a associates ttie isochronous 
channel secured on the local bus 14a by the termi- 
nal device 31a with the iPlug 193a on the local bus 
side by performing a write transaction (data write) 
with respect to the iPCR 1 92a on the local bus side 
after the portal 12a acquires the isochronous 
resources of the bridge bus 13 and the local bus 
14b. Further, the portal 12a associates the iso- 
chronous channel secured on the bridge bus 13 by 
the portal 12a with the oPIug 194a on the bridge 
bus side by performing a write transaction with 
respect to the oPCR 191a on the bridge bus side. 

(1 1) Then, the portal 12a performs a lock transac- 
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tion 251a similar to, for example, the above men- 
tioned write transaction 195a with respect to the 
iPCR 192b on the bridge side of the portal 12b and 
the oPCR 191b on the local bus side. With this 
transaction, the isochronous channel secured on 5 
the bridge bus 13 by the portal 12a Is associated 
with the iPlug 193b on the bridge bus side and the 
isochronous channel secured on the local bus 1 4b 
by the portal 12b is associated with the oPIug 194b 
on the local bus side. 10 

Thereafter, the portal I2a receives a write 
response 251 b transmitted from the portal 1 2b. 

Fig. 32 shows operations of respective portions 
of the serial bus network shown in Fig. 1 1 when the 
portals 1 2a and 1 2b associate their plugs with each is 
other. 

As shown in Fig. 32, 

(12) the portal 12a updates the content of the 
CHANNEL_SWITCH register 25a such that the 
oPIug 194a and the IPlug 193a are associated with 20 
each other. Then, the portal 12a associates the 
iPlug 193b with the oPlug 194b by performing a 
write transaction 261a with using a similar proce- 
dure to that of, for example, the above mentioned 
write transaction 199a with respect to the 25 
CHANNEL.SWITCH register 25b. 

Thereafter, the portal 12a receives the write 
response 261b transmitted by the portal 12b. 

(13) Thereafter, it transmits the asynchronous 
packet (no data) 262 addressed to the terminal 30 
device 31a to the local bus 14a. In response to the 
asynchronous packet (no data) 262. the terminal 
device 31a starts a transmission of the isochronous 
packet. 

35 

[01 01 ] Fig. 33 shows a flow of the isochronous packet 
2143 in the serial bus network shown in Fig. 11. The 
flow of the isochronous packet 241 shown in Rg. 33 is 
substantially the same as that of the previously men- 
tioned Isochronous packet 191 1 shown in Fig. 26. 40 
[0102] Through the above mentioned procedures, the 
terminal device 31 a in case 2 transmits the isochronous 
packet to the terminal device 31b. 
[0103] In the above mentioned procedures, the iso- 
chronous resource is secured first on the local bus 1 4a 4S 
and, then, the isochronous resources are secured on 
the bridge bus 1 3 and the local bus 1 4b in sequence. 
However, the sequence of securing the isochronous 
resources on these three buses may be as long as the 
isochronous resources can be secured thereon. so 
[0104] Further, the isochronous resources are 
secured on the bridge bus 13, the local bus 14a and the 
local bus 14b by the terminal device 31b and, thereafter, 
the terminal device 31a may transmit the isochronous 
packet to these secured isochronous channel. ss 



(Second Embodiment) 

[01 05] Rg. 34 is a block diagram showing a construc- 
tion of an IEEE 1394 bridge according to a second 
embodiment of the present invention. 
[0106] Although, in the IEEE 1394 bridge 11 of the 
first embodiment of the present invention, the respective 
portals are star-connected to the bridge manager 15, 
the IEEE 1394 bridge 281 of the second embodiment of 
the present Invention Is constructed such that adjacent 
portals among portals 252a to 252n and a bridge man- 
ager 255 included in the IEEE 1394 bridge 281 are con- 
nected by bridge buses 253 to form a chain as a whole. 
That is, the respective portals 252a to 252n and the 
bridge manager 255 are connected in the daisy chain 
configuration as shown in Fig. 34. 
[0107] In the IEEE 1394 bridge 281 having the daisy 
chain connected portals, an increase of the number of 
portals is facilitated. That is, the extendibility of the IEEE 
1394 bridge is improved. 

[01 08] Although, in the IEEE 1 394 bridge according to 
the first or second embodiments of the present inven- 
tion, the bridge manager is provided independently of 
the portals, the portals and the bridge mariager are not 
always provided separately and one of the portals may 
have a concurrent function of the bridge manager 
[01 09] Further, the bridge bus 1 3 and the local buses , 
1 4a to 1 4n do not always constitute the serial bus stand- 
ardized by the IEEE 1394 and may be any bus so long 
as it can transmit a serial data isochronously and asyn- 
chronously between terminal devices and portals con- 
nected to same buses. 

[0110] As described, the IEEE 1394 bridge of the 
present invention can be realized by using a usual com- 
puter system without using any system dedicated 
thereto. For example, it is possible to construct the IEEE 
1394 bridge for executing the previously mentioned pro- 
cedures by installing a program for executing the above 
procedures In a micro computer from a medium (ROM, 
etc., which can be inserted into and/or detached from a 
socket) storing the program. 

[0111] The medium for supplying the computer pro- 
gram may be a communication medium (a medium 
holding a program temporarily and runningly such as a 
communication circuit, communication network or com- 
munication system). For example, the program may be 
posted on a billboard (BBS) of a communication net- 
work and delivered through the network. 
[0112] Then, the above procedures can be executed 
by activating this program and executing it under a con- 
trol of an OS, like other application programs. 
[01 13] In a case where the OS bears a portion of the 
procedures or the OS constitutes a portion of the consti- 
tutional components of the present invention, the 
recording medium may store the program excluding that 
portion. In such case, the recording medium stores a 
program for executing respective functions or steps to 
be executed by the computer. 
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[0114] As described hereinbefore, a first effect of the 
pr^ent invention is that the IEEE 1394 bridge capable 
of improving the bus utilization is realized by performing 
the initialization of the network and the re-definition of 
topology while avoiding reduction of the bus utilization 
when a connection of a new active line to the serial net- 
work or disconnection of an existing active line from the 
serial network occurs. The reason for this is that, when 
a new active line is connected to or an existing active 
line is disconnected from the serial bus, the serial bus is 
initialized and the topology is re-defined, separately 
from others. 

[0115] A second effect is that the IEEE 1394 bridge 
capable of connecting 64 or more terminal devices 
within the serial bus network can be realized. The rea- 
son for this is that the serial bus network is constructed 
by connecting a plurality of independent serial buses. A 
third effect of the present invention is that the IEEE 1 394 
bridge capable of utilizing the resources efficiently by 
managing resources of a plurality of serial buses mutu- 
ally connected by the IEEE 1394 bridge, mutually inde- 
pendently, within the serial bus network : constituted by 
these serial buses. The reason for this is that the man- 
agement of resource is performed every serial bus. 
[01 16] A fourth effect of the present invention is that a 
bridge, particularly, the IEEE 1394 bridge, capable of 
transferring an asynchronous packet between different 
serial buses within the serial bus network having a plu- 
rality of serial buses mutually connected by the bridge is 
realized. The reason for this is that the bridge (including 
the IEEE 1394 bridge) of the present invention has a 
function of discriminating a destination of an asynchro- 
nous packet transmitted by a terminal and transferring 
the asynchronous packet to a serial bus to which a des- 
tination terminal device is connected. 
[0117] A fifth effect of the present invention is that a 
bridge, particularly, the IEEE 1394 bridge, capable of 
transferring an asynchronous packet between different 
serial buses within the serial bus network having a plu- 
rality of serial buses mutually connected by the bridge is 
realized. The reason for this is that the bridge (including 
the IEEE 1394 bridge) of the present invention has a 
function of securing an isochronous channel for trans- 
mitting an isochronous packet between mutually differ- 
ent serial buses. 

[0118] It should be noted that the present invention is 
not limited to the described embodiments and various 
modifications of the disclosed embodiments will 
become apparent for persons skilled in the art upon ref- 
erence to the description of the invention. 

Claims 

1 , A bridge comprising a plurality of portals connected 
to different local buses connected to external termi- 
nal devices and an internal bus for connecting said 
portals mutually, wherein each said portal com- 
prises: 
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topology information memory means for storing 
a topology information indicative of said local 
buses to which respective said terminal 
devices are connected: 

5 packet receiving means for receiving asynchro- 

nous transmission packets sent from said ter- 
minal devices and said portals connected 
through one of said local buses through said 
internal bus; and 

10 packet discrimination means for discriminating 

said local bus connected to a destination on the 
basis of the destination described in said asyn- 
chronous transmission packet received by said 
packet receiving means arKi the topology infor- 

75 mation stored in said topology information 

memory means, sending the asynchronous 
packet to said portal connected to said bcal 
bus when a result of discrimi ration of said 
packet discrimination means indicates a bcal 

so bus different from that to which said portal is 

connected and sending the asynchronous 
transmission packet to said local bus to which 
said portal is connected when the result of dis- 
crimination of said packet discrimination 

25 means indicates the same local bus as said 

local bus to which said portal is connected. 

2. A bridge as claimed in claim 1 , wherein said bridge 
is an IEEE 1394 bridge and said local buses are 

30 IEEE 1394 serial buses, respectively. 

3. A bridge as claimed in claim 1. wherein said topol- 
ogy information memory- means comprises: 

35 topology re-definition means for detecting a 

change of the number of said terminal devices 
connected to said local bus connected to said 
portal to which said topology information mem- 
ory means belongs, specifying said terminal 

40 device connected to said local bus after the 

detection of the change of the number of said 
terminal devices and supplying an information 
indicative of said specified terminal device to 
other said portals; and 

45 topology infornnation update means for produc- 

ing a new topology information by combining 
the information supplied from said topology re- 
definition means of said other portals and the 
topology information stored by said portal and 

so storing the new topology information. 

4. A bridge as claimed in claim 1. further comprising 
internal bus resource managing means for receiv- 
ing the asynchronous transmission packet for 

55 requesting a security of an isochronous channel for 
performing an isochronous transmission of a packet 
and securing the isochronous transmission channel 
on said internal bus, wherein said portal comprises: 
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local bus resource managing means for receiving 
the asynchronous transmission packet for request- 
ing the security of the isochronous transmission 
channel and securing the isochronous transmission 
channel on said local bus connected to said portal; 5 



an Input port for receiving the isochronous 
transmission packet through said isochronous 
transmission channel assigned as a source of 
an Isochronous transmission packet transmit- 10 
ted by the Isochronous transmission; 
an output port for acquiring the isochronous 
transmission packet from said input port 
assigned as the source of the isochronous 
transmission packet and sending the iso- is 
chronous transmission packet to the iso- 
chronous transmission channel assigned as 
the source of the isochronous transmission 
packet; and 

channel control means for assigning the iso- 20 
chronous transmission channel which 
becomes the source of the isochronous trans- 
mission packet to said input port, said input 
port which becomes the source of the iso- 
chronous transmission packet to said output 25 
port and said isochronous transmission chan- 
nel which becomes a destination of the iso- 
chronous transmission packet supplied by said 
output port. 

30 

5. A bridge as claimed in daim 4. wherein said at least 
one portal comprises said internal bus resource 
managing means. 

6. A bridge as claimed in daim 4. wherein said portals 35 
are connected through said internal buses to said 
internal bus resource managing means. 

7. A bridge as claimed in claim 4, wherein said portals 
and said internal bus resource managing means 40 
are connected through said internal buses to form a 
chain having no branch. 
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